Skip to content

Conversation

@polatolu
Copy link
Contributor

@polatolu polatolu commented Oct 8, 2025

Description

Added a User-Agent HTTP header to network calls. Uses the package's version at runtime, if it is not available sends it as "unknown"

Also added a PR template, once this merged new PRs will come with this PR template.

Regression Test Recommendations

  • Test that User-Agent header is present in all HTTP requests with correct format: flagsmith-swift-ios-sdk/
  • Test fallback to "unknown" when version is not discoverable at runtime
  • Validate User-Agent appears in both REST API calls and SSE connections

Type of Change

  • ✨ New feature (non-breaking change which adds functionality)
  • 🛠️ Bug fix (non-breaking change which fixes an issue)
  • ❌ Breaking change (fix or feature that would cause existing functionality to change)
  • 🧹 Code refactor
  • ✅ Build configuration change
  • 📝 Documentation
  • 🗑️ Chore

Unit Test Results

Screenshot 2025-10-08 at 20 17 07

@polatolu polatolu requested a review from a team as a code owner October 8, 2025 09:15
@polatolu polatolu requested review from kyle-ssg and removed request for a team October 8, 2025 09:15
@matthewelwell matthewelwell changed the title Feature/send user agent header feat!: send user agent header Oct 30, 2025
Copy link

@emyller emyller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall! Couple comments.

"Version part should be a semantic version number (e.g., 3.8.4), got: \(versionPart)")

// Should be the expected SDK version
XCTAssertEqual(versionPart, "3.8.4", "Expected SDK version 3.8.4, got: \(versionPart)")
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have to update this assertion on every version bump?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(additional context here) I think this can be improved with release please, yes.

You'll need to add the file to the list of additional files here, and then add comments in here to tell release please where to update.

Suggested change
XCTAssertEqual(versionPart, "3.8.4", "Expected SDK version 3.8.4, got: \(versionPart)")
// x-release-please-start-version
XCTAssertEqual(versionPart, "3.8.4", "Expected SDK version 3.8.4, got: \(versionPart)")
// x-release-please-end

Comment on lines 33 to 49
/// Get the SDK version from the bundle at runtime
/// Falls back to hardcoded constant or "unknown" if version is not discoverable
private static func getSDKVersion() -> String {
// Try CocoaPods bundle first
if let bundle = Bundle(identifier: "org.cocoapods.FlagsmithClient"),
let version = bundle.infoDictionary?["CFBundleShortVersionString"] as? String,
!version.isEmpty,
version.range(of: #"^\d+\.\d+\.\d+"#, options: .regularExpression) != nil {
return version
}

// Try SPM bundle
if let version = Bundle(for: Flagsmith.self).infoDictionary?["CFBundleShortVersionString"] as? String,
!version.isEmpty,
version.range(of: #"^\d+\.\d+\.\d+"#, options: .regularExpression) != nil {
return version
}
Copy link

@emyller emyller Oct 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we're OK manually checking a semver-like pattern here, though we could maybe rely on semver parsing for future-proofing, in case we occasionally adopt build or pre-releases metadata.

Comment on lines 21 to 23
/// SDK version constant - should match the podspec version
/// This is used as a fallback when bundle version detection fails
private static let sdkVersionConstant = "3.8.4"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand the resilience this adds given the platform, though this may prompt for some process that ensures code will be kept in sync with the actual version tagged.

@polatolu Do you think we need to implement some kind of CI script to accomplish this? Alternatively, would you consider falling back to "unknown" when bundle version detection fails?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possible we need to add this to the release please config as well to resolve this? See instructions here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants